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Abstract 

This  paper  discusses  research  efforts  at 
the  Naval  Research  Laboratory  (NRL)  in 
the  area  of  environmentally  adaptive 
navigation  and  dynamic  mission 
planning.  Presented  in  this  paper  is  the 
system  architecture  being  developed  for 
the  accomplishment  of  objective  based 
dynamic  navigation.  A  simulator  is 
being  constructed  that  incorporates  this 
architecture  and  its  design  is  presented. 
This  simulator  will  enable  the  future 
development  of  specific  mission 
behavior  modules. 

I.  Introduction 

Objective  based  dynamic  navigation 
planning  addresses  the  need  for  adaptive 
planning  and  execution  of  environmental 
surveys.  In  general  the  objective  of  a 
survey  is  not  to  simply  turn  a  sensor  on 
and  to  have  the  vessel  that  is  carrying  the 
sensor  navigate  through  a  series  of 
waypoints.  Rather,  the  typical  objective 
is  to  use  the  sensor  to  characterize  the 
environment  in  some  fashion;  for  swath 
type  sensors  (sidescan,  video, 
bathymetry,  altimetry,  etc.)  the  objective 
is  often  to  achieve  full  area  coverage  of  a 
terrain.  The  design  of  a  survey  planning 
and  execution  system  should  thus  be 


built  around  the  objective  of  a  particular 
survey  using  realistic  system/vessel 
models  for  survey  planning  or  in  situ 
assessment  of  sensor/vessel  performance 
for  survey  execution. 

The  research  exhibited  here  is  part  of  the 
Environmentally  Adaptive  Navigation 
(EAN)  effort  at  the  Naval  Research 
Laboratory  that  primarily  focuses  on 
adaptive  navigation.  The  rational  behind 
this  focus  is  that  given  an  estimate  (or  in 
situ  measurement)  of  a  particular 
sensor’s  characteristics,  the  problem  of 
achieving  the  stated  mission  objective 
typically  becomes  a  problem  of 
deploying  the  sensor  at  the  proper 
positions  and  orientations  -  i.e.  vessel 
navigation.  In  particular,  this  research 
focuses  on  achievement  of  mission 
objectives  with  fully  autonomous  vessels 
without  the  benefit  of  human  judgment 
to  contend  with  unforeseen 
circumstances.  EAN  is  building  on  the 
previous  AutoSurvey  [1]  work  at  NRL 
and  is  concentrating  on  swath  type 
sensors  at  this  point  in  the  research. 

The  present  research  effort  is  the 
development  of  an  EAN  simulator.  The 
goal  for  this  simulator  is  to  provide  a 
flexible  and  generic  platform  for 
objective  based  planning  of  surveys  with 


multiple  types  of  vessels  and  sensors, 
and  will  encompass  the  AutoSurvey 
algorithms  as  part  of  its  initial 
development.  The  AutoSurvey  system 
generates  adaptive  navigation  lines  for 
bathymetric  surveys  within  a  defined 
boundary  and  is  being  transitioned  to  the 
NAVOCEANO  hydrographic  survey 
fleet.  AutoSurvey  provides  only  one  of 
the  many  intelligent  behaviors  that  will 
be  required  to  optimally  and 
autonomously  conduct  a  full  swath 
sensor  survey.  The  architecture  of  the 
EAN  system  discussed  in  this  paper 
strives  for  the  ability  to  easily 
incorporate  new  system  behaviors  as 
they  are  developed. 

The  EAN  simulator  will  also  provide  an 
excellent  tool  for  planning  swath  sensor 
surveys.  It  is  designed  to  take  into 
account  the  sensor  footprint  on  the 
terrain  being  surveyed,  and  thus  its 
accuracy  in  predicting  sensor  coverage 
and  time  in  survey  will  be  better  than 
traditional  flat  bottom  or  rule  of  thumb 
methods.  This  will  allow  survey 
planners  to  get  a  better  idea  of  the 
required  direction,  shape  and  spacing  of 
the  survey  lines  required  to  meet  the 
mission  objective.  In  doing  so,  time  at 
sea  and  survey  distance  can  be 
minimized,  and  survey  area  coverage 
can  be  optimized.  A  secondary  function 
of  this  research  is  the  study  of  various 
coverage  patterns  and  maneuvering 
techniques  and  their  effect  on  survey 
coverage  and  time-in- field  efficiency. 

This  next  section  of  this  paper  provides 
some  background  on  the  need  for 
environmentally  adaptive  navigation  and 
discusses  the  primary  design  objectives 
of  the  EAN  simulator.  Section  III 
discusses  the  system  architecture  and 
functional  system  design  to  achieve  an 


objective  based  adaptive  navigation 
system.  Finally,  Section  IV  summarizes 
the  EAN  simulator  development  and 
discusses  future  planned  efforts. 

11.  EAN  System  Background 

Environmentally  adaptive  navigation  for 
swath  sensors  is  of  particular  importance 
due  to  the  variations  that  can  occur  in  a 
sensor’s  achieved  coverage  area.  Swath 
sensors  typically  have  a  fixed  angular 
swath  that  translates  to  a  variable 
footprint,  the  size  of  which  depends  on  a 
multitude  of  factors.  For  a  vessel 
traveling  in  level  flight,  variations  in  the 
distance  from  the  vessel  to  the  terrain 
cause  a  change  in  the  swath  width;  the 
greater  the  altitude  over  the  terrain,  the 
greater  the  swath  width.  Variations  in 
swath  width  are  also  experienced  for 
constant  altitude  (terrain  following) 
vessel  flight  due  to  rough  terrain, 
crabbing,  and  occlusion. 

Clearly,  adaptive  navigation  is  needed  to 
optimize  vessel  deployment,  i.e.,  to 
ensure  full  area  coverage  and  to 
minimize  wasted  time.  Ideally,  swatb 
sensor  operations  would  utilize  dynamic 
mission  planning  during  the  execution  of 
a  deployment.  Dynamic  mission 
planning  utilizes  adaptive  navigation 
based  on  the  in  situ  assessment  of 
mission  objective  accomplishment  as 
realized  by  the  actual  vessel  sensor 
performance.  This  is  obviously 
preferred  over  pre-mission  planning, 
because  decisions  are  made  based  on 
current,  local  sensor  data  instead  of 
based  on  predicted  data  from  models  or 
databases  and  assumed  sensor 
performance. 

Mission  planning  for  a  swath  sensor 
based  survey  is  typically  accomplished 


using  greatly  simplifying  assumptions  on 
the  vessel,  sensor  and  area  terrain,  and 
generates  a  series  of  evenly  spaced 
parallel  lines.  Consequently, 

significantly  better  pre-mission  planning 
can  be  achieved  using  adaptive 
navigation  that  incorporates  better 
models  of  sensor  and  vessel  performance 
as  well  as  the  best  knowledge  available 
on  the  area  terrain. 

Because  the  placing  of  the  vessel/sensor 
in  the  desired  location  and  orientation  is 
fundamental  to  successful 

accomplishment  of  most  phases  of 
survey/search  operations  in  general,  the 
focus  of  the  BAN  system  has  been 
primarily  on  adaptive  navigation.  The 
architecture  of  the  system  was  designed 
to  facilitate  the  study  and  development 
of  other  survey/search  related 
operations,  including  obstacle  avoidance 
and  continuation  of  a  mission  after 
unavoidable  interruption  (i.e.,  deviation 
from  the  planned  track).  The  design 
goal  of  the  BAN  simulator  was  to  create 
a  suite  of  software  modules  that  work 
together  to  simulate  realistic  data 
collection  surveys  in  which  the  primary 
sensor  system  is  swath  based. 

From  the  outset,  the  thinking  on  the 
BAN  project  was  to  go  beyond  a  simple 
simulator  implementation  of  AutoSurvey 
and  to  create  a  portable  UUV  data 
collection  and  navigation  system  whose 
architecture  would  lend  itself  to  the 
incremental  integration  of  new 
capabilities. 

The  system  was  also  specifically 
designed  to  provide  a  platform  to 
develop,  implement  and  test  new 
dynamic  mission  planning  algorithms. 
\^ile  the  primary  objective  of  the 
present  BAN  development  was  the 


development  of  a  simulator,  a  flexible 
architecture  goal  was  pursued  to 
facilitate  transitions  to  vessel  control 
systems.  This  design  goal  was  to  be 
accomplished  by  the  clear  delineation  of 
specific  system  dependent  and 
independent  funetions.  Key  algorithms 
such  as  next  line  generation  and  obstacle 
avoidance  were  to  be  part  of  system 
independent  libraries,  while  access  to 
aetual  sensors,  motors,  and 
communications  equipment  (or  their 
simulated  counterparts)  were  to  be 
handled  by  a  set  of  operational 
application  program  interfaces  (APIs).  A 
transition  firom  the  simulator  to  a 
physical  system  would  thus  involve 
changing  the  data  path  of  the  t^sensor 
driver”  and  the  “navigation  driver” 
modules  from  simulated  data  to  physical, 
real  world  data. 

Key  design  features  of  the  BAN 
simulator  include: 

•  Generation  of  more  realistic  sensor 
swath  coverage  estimates  by  using  better 
models  for  the  environment,  vessel  and 
sensor: 

o  Utilization  of  a  digital  terrain  map 
(DTM)  of  the  area 

o  Simulated  survey  vessel 
performance  bounded  by  the  target 
vessel’s  attributes  -  bounded  turn  and 
acceleration/deceleration  rates.  The 
simulated  vessel  should  not  be 
allowed  to  execute  maneuvers  that  a 
real  vessel  could  not.  Vessel  flight 
modes  should  include  level  flight  or 
terrain  following.  A  generic  vessel 
model  is  desired  that  can  easily 
represent  any  target  vessel  given  a 
defined  set  of  maneuvering 
characteristics. 

0  Sensor  model  that  includes 
maximum  slant  ranges,  occlusion 


detection  and  sensor 

orientation/position  with  respect  to  the 
terrain  map.  A  generic  sensor  model 
is  desired  that  ean  easily  represent  a 
large  variety  of  swath  type  sensors 
with  just  a  change  of  parameters. 

•  3d  graphic  representation  showing 
the  survey  area,  the  ships  progress, 
current  sensor  field  of  view,  and  current 
accumulated  survey  statistics 

•  The  ability  to  use  a  variety  of  vessel 
navigation  methods  including  parallel, 
uniformly  spaced,  preplanned  lines  and 
lines  that  are  adaptively  generated  using 
the  AutoSurvey  [1]  algorithms. 

•  The  ability  to  easily  integrate  new 
behavior  modules  required  to 
accomplish  specific  mission  objectives 

•  Assessment  of  mission  performance 
in  terms  of  required  mission  time  and 
achieved  sensor  area  coverage. 

•  The  ability  to  generate  track  line 
waypoints  that  could  be  used  for  an 
actual  vessel  survey. 

•  The  ability  to  run  the  system  on  a 
single  machine,  or  in  a  distributed  mode 
over  a  network. 

•  A  system  architecture  that  lends 
itself  to  migration,  in  whole  or  in  part, 
into  physical  vessel  systems.  By 
replacing  modules  such  as  the  swath 
sensor  simulator,  vessel  motion 
simulator,  etc,  with  their  physical 
counterparts,  the  transition  can  be  made 
in  an  incremental  manner. 

in.  Architecture  and  Functional 
Design 

The  design  of  the  EAN  simulator  is 
described  in  the  following  subsections. 
The  design’s  conceptual  and  functional 
issues  will  be  discussed  as  well  as  those 
that  concern  the  implementation  of  the 
system. 


A.  System  Architecture 

1.  Objective  based  conceptual  Architecture 


Figure  1  below  illustrates  the  conceptual 
view  of  the  system,  fi'om  a 
decision/thought  process  point  of  view. 
Figure  l.a  is  a  general  system  that  may 
or  may  not  include  navigation.  Figure 
l.b  is  one  step  less  general  and  is 
focused  on  navigation.  The  main  idea  is 
that  the  autonomous  entity  can 
determine  its  next  action,  given  its  state 
at  some  point  in  time,  based  on  its 
perception  of  the  environment,  and  a 
toolbox  of  goal  oriented  algorithms.  The 
action/sensor  feedback  loop  guides  the 
autonomous  entity  towards  its  goals. 
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Figure  b. 


Figure  1.  These  two  figures  show  the  overall 
conceptual  view  of  the  EAN  system.  Figure  a. 
shows  the  conceptual  view  of  a  multipurpose 
system,  while  figure  b.  shows  the  navigation 
system. 


In  its  current  state  the  EAN  simulator 
would  most  closely  match  Figure  l.b 
with  the  understanding  that  there  is  only 
one  goal  based  set  of  algorithms,  those 
of  the  AutoSurvey  library.  A  logical 
progression  for  the  system  is  to  develop 
the  ability  to  avoid  obstacles  and  to 
optimally  recover  the  data  missed  during 
the  obstacle  avoidance  maneuver.  Other 
functionality  such  as  a  power  saving 
mode,  or  a  feature-seeking  mode,  would 


enhance  the  value  of  the  system.  These 
functions  would  all  be  system 
independent  to  the  extent  that  they  can 
be  modeled  based  on  generic  sensor 
types  (swath,  point,  profile,  etc.)  as 
opposed  to  specific  system  interfaces 
and  data  formats.  Figure  2  shows  a 
conceptual  flow  diagram  incorporating 
these  features. 
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Figure  2.  This  figure  shows  the  interaction  of 
several  generic  functionality  modules.  The 
Arbitrator  module  sorts  out  any  conflicts  so 
that  the  input  to  the  Autopilot  is  a  coherent 
set  of  navigation  objectives. 

Note  that  in  Figure  2  vessel  positions 
and  sensor  data  are  concurrently 
available  to  each  different  type  of 
functionality.  The  Arbitrator  module 
resolves  any  conflicts  that  may  arise 
from  the  different  functionality  modules 
so  that  a  coherent  stream  of  positions  is 
passed  to  the  Autopilot. 

2.  Mission  Objectives  Arbitration 

Since  multiple  navigation  objectives 
may  exist  at  any  given  time,  an 
arbitration  scheme  is  required  to  choose 
the  correct  system  behavior.  A 
subsumption  approach  is  taken  in  the 
FAN  system  design  for  the  arbitration. 
The  architecture  shown  in  Figure  2  is 
based  on  Rodney  Brooks’  Subsumption 
Architecture  [2].  Subsumption,  as  it  was 


originally  labeled,  was  introduced  as  a 
method  to  control  mobile  autonomous 
robots  that  operate  in  an  unstructured 
environment.  Later  articles  refer  to  it  as 
Behavior  programming. 

Subsumption  methods  have  been  used 
effectively  to  control  robots  in  various 
settings  where  multiple  behaviors  are 
needed  to  produce  the  desired 
functionality.  MIT’s  Allen  robot  [4]  was 
programmed  to  wander,  seek  out 
distances  far  from  it,  and  avoid  objects. 
A  more  complex  functionality  was 
achieved  by  using  more  behaviors  in 
MIT’s  Herbert  robot.  It  was  able  to 
operate  into  cluttered  office  spaces  while 
people  were  present.  Its  purpose  was  to 
go  in  to  offices  and  collect  empty  soda 
cans.  By  combining  various  behaviors 
such  as  wandering,  wall  following, 
obstacle  avoidance,  can  recognition,  and 
grasping,  Herbert  was  able  to  do  useful 
work  in  a  changing  unstructured 
environment.  It  did  not  use  world 
models  and  there  was  minimal  inter¬ 
behavior  communication.  Most  of  the 
inter-behavior  communication  was 
accomplished  by  using  the  environment 
as  the  information  transmission  medium. 

The  above  examples  describe  systems  of 
opportunity,  sometimes  referred  to  as 
reactive  systems.  The  systems  work 
well  because  their  hierarchy  of  responses 
to  sensor  inputs  is  set  up  well  for  the 
environment  they  inhabit.  Since  there  is 
no  modeling  of  the  environment  or  any 
part  of  it,  there  can  be  no  optimization. 
Some  hierarchies  may  be  more  effective 
than  others,  but  because  of  the  lack  of  a 
modeling  structure,  there  are  no 
preplanned  events. 

Conversely,  cognitive  systems  use  a 
world  model  on  which  to  base  their 


decisions.  The  world  model  can  either 
be  pre-programmed  or  built  with  sensory 
inputs.  If  the  model  is  correct  and  can 
remain  updated,  and  the  computing 
equipment  has  adequate  speed  for  the 
given  task,  system  events  can  be  planned 
with  a  degree  of  optimization. 

There  is  no  requirement  that  a  system  be 
all  reactive  or  all  cognitive.  Ferber  [5] 
describes  a  hierarchy  of  modules  for  an 
explorer  robot  based  on  a  subsumption 
architecture  in  which  the  more  reflexive 
modules,  like  obstacle  avoidance  and 
replenishing  energy,  can  subsume  the 
cognitive  behaviors,  like  making  maps 
and  exploring. 

3.  Subsumption  Based  EAN  Architecture 

Figure  3  shows  the  EAN  survey 
functions  as  a  similar  hierarchy.  As  in 
Ferber’s  explorer  robot,  the  more 
reactive  behaviors  dominate  the 
cognitive  behaviors. 


Figure  3.  Model  of  the  EAN  system  based  on 
subsumption  architecture.  Note  that  the  more 
reactive  modules  such  as  avoiding  obstacles 
have  precedence  over  the  cognitive  modules. 

EAN  is  set  up  using  a  subsumption  like 
architecture.  Although  subsumption  is 
usually  associated  with  reactive  systems, 
in  EAN  some  of  the  behavior  modules 
will  be  cognitive,  e.g.,  the  Autosurvey 


module.  The  more  reactive  modules  will 
be  higher  in  the  hierarchy  than  the 
cognitive  modules.  The  overall 
functionality  will  be  that  of  a  system  that 
spends  most  of  its  time  and  resources 
executing  primary  goal  modules,  i.e.,  the 
survey  control  routines  in  the 
AutoSurvey  module.  But  when  the 
occasion  arises,  the  more  reactive 
modules  (e.g.,  obstacle  avoidance)  will 
subsume  the  goal  modules.  As  in  other 
applications  of  subsumption,  all  modules 
will  execute  in  parallel  and  each  will 
have  access  to  the  sensor  data  that  they 
need. 

The  interior  architecture  of  the  various 
behavior  modules  of  EAN  may  or  may 
not  be  subsumption  based.  Because  the 
obstacle  avoidance  module  is  by  nature 
reactive,  it  will  likely  be  subsumption 
based,  while  the  more  cognitive 
AutoSurvey  module  will  not.  Thus,  in 
cases  where  needed,  subsumption  will  be 
nested. 

The  EAN  system  behavior  hierarchy  will 
be  static  during  actual  surveys,  thus 
increasing  system  predictability.  The 
system  designers  will  establish  the  initial 
hierarchy,  but  a  statistical  hierarchy- 
arranging  scheme  similar  to  that  used  by 
Maes  [3]  for  walking  robots  will  be 
investigated.  The  effectiveness  of 
hierarchies  derived  from  several 
different  survey  scenarios  will  be 
compared. 

B.  System  Functional  Design 

The  EAN  simulator  is  a  suite  of  software 
modules  that  work  together  to  create  a 
swath  sensor  simulation  system, 
including  vessel  and  sensor  simulation 
modules.  The  modules  are  arranged  into 
four  distinct  levels  of  abstraction.  In 
general,  all  modules  in  a  particular  level 


are  related  to  one  another  either  by 
function,  or  by  attribute.  By  using 
levels,  the  software  can  be  constructed 
and  tested  in  an  incremental  manner. 
This  methodology  can  also  be  used  to 
increase  the  portability  of  the  system. 

1.  Advantages  and  Disadvantages  of  the 
Multi-Level  Approach 

The  main  advantage  of  arranging 
software  in  levels  is  complexity 
reduction  due  to  abstraction  and 
modularity  [6].  By  hiding  the  details  of 
operation  from  level  to  level,  the  infra 
level  complexity  is  reduced.  In  general, 
upper  levels  deal  with  conceptual  issues 
while  lower  levels  handle  the  mechanics 
of  getting  the  work  done.  Portability  and 
ease  of  development  and  testing  are  also 
distinct  advantages  of  multi-level  design. 

Because  of  the  distinct  separation  of  the 
various  software  modules,  this  approach 
may  not  lend  itself  to  embedded 
systems,  or  to  systems  that  are  limited  by 
memory  or  speed.  The  inter-module 
communication  protocols  cost  the 
system  time  when  compared  to  making 
direct  calls.  The  hiding  of  details  by 
levels  of  abstraction  has  a  similar  effect 
in  that  it  increases  the  average  height  of 
the  runtime  stack,  thus  requiring  more 
time  and  memory.  Because  of  the 
increased  average  stack  height,  more 
time  is  spent  managing  the  parameters 
associated  with  module  calls  than  would 
be  spent  in  a  comparable  tightly  coupled 
system. 

2  EAN  Levels 

The  EAN  software  is  arranged  into  four 
distinct  levels.  It  is  similar  to  the  UNIX 
system  layout  in  that  there  is  one  level 
that  is  system  dependent.  Level  4.  One 
of  early  design  goals  was  to  create  an 


architecture  in  which  there  existed 
clearly  defined  API’s  and  a  separation  of 
system  dependent  and  independent 
modules.  The  separation  of  dependent 
and  independent  functions  is  described 
in  more  detail  in  the  EAN  level  3 
discussions.  The  separations,  or  levels, 
were  to  be  hierarchical  in  nature,  i.e.. 
Level  1  modules  rely  on  Level  2 
modules.  Level  2  modules  rely  on  Level 
3  modules  and  so  forth.  The  big 
difference  between  UNIX  and  the  EAN 
system  is  that  much  user  interaction  and 
processing  occurs  at  the  system 
dependent  level  (Level  4)  in  EAN, 
whereas  in  UNIX  the  system  dependent 
layer  is  the  furthest  removed  from  the 
user.  So  in  this  regard  the  EAN 
architecture  is  somewhat  like  an  inverted 
UNIX  structure. 

Figure  4  shows  generic  Level  1  and 
Level  2  modules.  The  Level  1  module 
contains  algorithms  that  are  designed  to 
generate  navigation  waypoints  that 
achieve  certain  objectives  given  the 
navigation  data  and  the  mission  sensor 
data.  The  function  of  the  Level  2 
module  is  to  validate  the  incoming  data 
to  ensure  that  it  complies  with  the 
assumptions  that  are  made  by  the  Level 
1  algorithms  about  the  data.  For 
complex  Level  1  algorithms,  many 
assumptions  about  the  incoming  data 
may  be  required  and  a  violation  of  any 
of  these  assumptions  could  cause  the 
module  to  fail,  or  worse,  to  generate 
undetected  erroneous  results. 

While  it  would  be  desirable  to  have  the 
Level  2  modules  strictly  system 
independent,  this  is  not  practical  for 
more  complex  sensors.  Consequently, 
the  Level  2  task  of  data  validation  has 
been  divided  between  both  system 
dependent  and  system  independent  tasks. 


In  particular,  a  data  validation  task  such 
as  ensuring  that  the  data  meets  certain 
quality  constraints  is  very  likely  to  be 
specific  to  a  particular  sensor. 


Mission  Sensor  Na\igation 


Figure  4.  Level  1  and  Level  2  Modules.  Level 
1  modules  generate  navigation  waypoints 
given  navigation  data  and  mission  sensor 
data.  Level  2  modules  validate  the  incoming 
data  to  ensure  that  it  complies  with  the 
assumptions  made  by  the  Level  1  algorithms. 
The  blue  Interfaces  are  system  independent, 
API  defined  interfaces.  The  yellow  interfaces 
are  system  dependent. 

Figure  5  shows  an  example  of  a  generic 
Level  3  module.  Level  3  modules 
incorporate  the  Level  1  and  system 
independent  Level  2  modules.  Each 
Level  3  module  is  assigned  a  specific 
goal  oriented  task.  Each  module 
requires  navigation  data  (position, 
orientation,  time,  etc.)  and  one  or  more 
mission  sensor  inputs.  The  Level  3 
modules  include  functionality  for: 

■  Acquisition  of  navigation  and 
mission  sensor  data;  event-driven,  either 
at  periodic  intervals  or  continuously 

■  Event  detection  software  that  detects 
(using  mission  sensors  and/or  navigation 
data)  when  it  needs  to  go  active.  Certain 
activities,  such  as  end-of-line  turn 
computations,  go  active  only  when 
specific  events  occur.  Other  Level  3 
modules,  such  as  obstacle  detection, 
would  be  continuously  active,  but  would 


only  generate  navigation  waypoints 
when  certain  events  occur.  Conceivably 
there  could  be  Level  3  modules  that 
combine  both  event  driven  and 
continuous  operations  in  order  to  meet 
their  objectives. 

■  Execution  of  the  Level  2  and  Level  1 
modules  when  required.  A  Level  3 
module  could  contain  several  Level  1 
modules  that  are  executed  either 
sequentially  or  in  tandem. 

■  Passing  of  generated  waypoints  to 
the  arbitration  module 

The  Level  3  modules  are  designed  to  be 
system  independent.  While  their 
interfaces  to  the  associated  mission 
sensors  will  likely  be  tailored  to  the 
specific  type  of  sensor,  they  will  not 
directly  contend  with  the  interface 
complexities  of  specific  pieces  of 
hardware. 

Figure  6  shows  EAN  Level  4,  as  well  as 
the  autopilot,  mission  sensors  and 
navigation  sensors  that  are  external 
systems.  Most  importantly.  Level  4  adds 
the  arbitration  module  that  determines 
which  set  of  Level  3  generated 
navigation  waypoints  is  to  be  passed  to 
the  autopilot  for  execution.  Level  4  also 
includes  the  translators  for  the 
navigation  sensors,  mission  sensors,  and 
the  generated  navigation  waypoints.  The 
translators  serve  strictly  to  convert  the 
device  independent  data  streams  used  by 
Level  3  to  the  system  specific  data 
streams  required  by  the  external  systems. 
The  translators  are  associated  with  Level 
3  instead  of  Level  4  since  many  Level  3 
modules  may  utilize  the  same  sensor 
inputs  and  duplication  of  the  associated 
translator  is  not  desired. 

It  is  important  to  note  that  this  system 
has  been  specifically  designed  to  be 


waypoint  centric  —  i.e.,  the  output  of 
each  Level  3  module  is  a  set  of  positions 
that  the  vessel  is  intended  to  reach.  This 
approach  was  taken  since  mission 
objectives  necessarily  dictate  that  the 
vessel  be  at  specific  positions  and 
orientations  in  order  to  accomplish 
mission  tasks.  While  direct  vessel 
control  (heading,  speed,  attitude,  etc.) 
may  be  suitable  for  certain  reactive 
behaviors  such  as  obstacle  avoidance,  it 
does  not  lend  itself  well  to  the  more 
cognitive  oriented  objective  based 
navigation.  A  waypoint-based  system 
however,  is  suitable  for  both  reactive 
and  cognitive  behaviors.  This 
architecture  lends  itself  directly  to  the 
inclusion  of  position  ‘qualifiers’. 
Simply  arriving  at  a  position  may  not  be 
sufficient  depending  upon  the  specific 
task.  Position  qualifiers  could  include 
such  things  as  time,  orientation  and 
maneuvering  aggressiveness. 


Figure  5.  Level  3  Module.  The  Level  3 
module  incorporates  Level  1  and  2  modules. 
The  Level  3  module  also  includes  the 
necessary  mechanisms  to  pass  data  into  and 
out  of  the  Level  3  module  and  to  execute  the 
Level  1  and  2  modules  at  the  appropriate 
times.  The  blue  interfaces  are  system 
independent,  API  defined  interfaces.  The 
yellow  interfaces  are  system  dependent. 

The  full  EAN  simulator  also  includes 
modules  for  the  autopilot,  the  vessel  and 
the  mission  sensors.  The  autopilot 
module  receives  the  waypoints  from 


Level  4  and  position  data  from  the  vessel 
module  and  generates  the  appropriate 
heading,  speed  and  depth/altitude 
commands  for  the  vessel  module  to 
execute.  The  vessel  module  realistically 
simulates  the  motion  of  a  vessel  and 
generates  the  navigation  sensor  outputs. 
The  mission  sensor  modules  uses 
archived  environmental  data  and  the 
navigation  data  from  the  vessel  module 
to  generate  realistic  sensor  data.  As  can 
be  seen  from  Figure  6,  EAN  Level  4 
should  be  readily  portable  from  a 
simulator  environment  to  a  real  vessel. 


Figure  6.  System  Level  4,  Level  4  includes  all 
the  Level  3  modules,  the  arbitration  module, 
and  system  specific  interfaces  to  navigation 
sensors,  mission  sensors  and  the  autopilot. 

IV.  Summary 

This  paper  presented  the  architecture  and 
design  of  the  Environmentally  Adaptive 
Navigation  (EAN)  simulator  system  that 
is  being  constructed  at  NRL.  The  EAN 
simulator  has  been  implemented  in  four 
distinct  levels  of  software.  This  design 
has  parallels  to  that  of  the  design  of  the 
UNIX  operating  system.  The  function 
of  the  levels  can  be  briefly  described  as 
follows: 

•  Level  1  -  A  basic  set  of  machine 
independent  algorithms  are  used  to 


generate  navigation  waypoints  based  on 
sensory  data  and  some  stated  objective. 

•  Level  2  -  Performs  input  data 
assumption  enforcement  to  ensure 
predictable  Level  1  operation. 

•  Level  3  -  Incorporates  the  Level  1 
and  2  modules  and  the  necessary 
mechanisms  to  execute  and  to  interface 
them  to  the  external  data  streams. 

•  Level  4  -  Provides  data  translation 
between  external  devices  (or  their 
simulated  counterparts)  and  the  device 
independent  Level  3  modules.  Level  4 
also  provides  arbitration  between 
competing  Level  3  objectives. 

A  partial  simulator  system  has  been 
completed  that  incorporates  the 
AutoSurvey  library  and  a  few  other 
simple  Level  1  modules.  Work 
continues  to  refine  the  Level  2  modules 
and  to  develop  the  remaining  Level  1 
behavior  modules  that  will  be  required  to 
autonomously  execute  an  entire  swath 
survey  in  an  optimal  fashion. 
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